The client-server model of computer process interaction is widely used. According to the client-server model, a client process sends a message including a request to a server process, and the server process responds by providing a service. The server process may also return a message with a response to the client process. Often the client process and server process execute on different computer devices, called hosts, and communicate via a network using one or more protocols for network communications. The term “server” is conventionally used to refer to the process that provides the service or the host computer on which the process operates; similarly, the term “client” is conventionally used to refer to the process that makes the request or the host computer on which the process operates. As used herein, the terms “client” and “server” refer to the processes, rather than the host computers, unless otherwise clear from the context.
A database server provides database services in response to requests from a database client. For example, the database server writes data received in the request into one or more data containers in a particular database managed by the database server; or, the database server retrieves data from one or more of those containers that satisfy conditions specified in the request; or, it does both. In many circumstances the database client is a mid-tier application, distinct from the database server, which performs other services, such as accounting services, for one or more application users. The application itself may be configured for client-server operations, so that application users operate application clients that make application requests to an application server.
When a database client sends a request to a database server, the database server establishes a database session object to hold information related to providing database services to that client. The session object is a data structure that stores information that supports a session. A session is a related series of one or more requests for services made over a communication channel. The channel is typically established by the operating system of the host for the database server and that persists for one or more communications from the client, depending on the communications protocol used by the client.
The session information stored in the database session object may include any information well-known in the art. The session information may also include security information, such as identities of clients and users associated with a request, and access privileges associated with those users. The database session object may also contain references to the database and database schema associated with the request and the amount and location of memory areas on the database server host where processes and data associated with the session are cached.
As database servers are extended to support more options and communication protocols and security protocols, the amount of information stored in a database session object is increased. For example, to support database requests for hierarchical data, such as files and folders of a file system stored in a repository within the database, the database session object is extended to include information about a root container for the hierarchy and a document that contains configuration information about the hierarchy, such as an XML schema document. To associate users or files with attributes of those users or files, hash tables are often used; in such circumstances the database session object may include the hash tables.
As a result of the many important pieces of information stored in a database session object, a significant amount of database server and server host resources are consumed in generating the database session object. Consumption of central processing unit (CPU) processing cycles are especially significant, leading to a perceived increase in response time needed for the database to return a result. When a client ends its communication session with the database server, the associated database server object is deleted and resources assigned to the database session object are released.
While suitable for many purposes, establishing a new database session object for every user who causes requests for database services does suffer some disadvantages. For example, when there are many database users who connect to and disconnect from the database frequently, the resources consumed by the database server to establish and release database session objects can noticeably increase database server response time and therefore decrease database server performance.
To improve response time, some mid-tier applications establish a pool of connections with a database server. The connections in the pool are maintained and reused by the application as different application users join and exit the application. On the database server, relatively few database session objects are established. Those that are established are associated with the application for the long-lived connections in the pool. Each time a different user is associated by the application with one of the connections in the pool, the application sends some data to the database server that causes a new session to be created.
While suitable for many purposes, there are some disadvantages to relying on mid-tier applications to re-use a pool of long-lived connections to the database server. One disadvantage is that the mid-tier application must be developed to establish and maintain the pool of connections. This increases the cost of developing and testing mid-tier applications that use the database server.
Another disadvantage is that an excess of database session objects may be generated because, while each application establishes a pool for its optimal number of users, it is unlikely that all applications will need to support their optimal number of users at the same time. For example, five mid-tier applications each expect a optimal number of ten (10) and therefore each establishes a pool of ten (10) database connections. As a result, 50 database session objects are generated on the database server. At any one time, some of those applications have fewer than ten users; for example, four (4) applications may have four (4) users when one has nine (14) users—for a total of 30 users. While the number of users at each application varies, the number of used connections to the database actually varies only slightly around 30. Therefore 50 database session objects are established to serve 30 used connections. The database server resources consumed to maintain the 20 excess database session objects wastes valuable resources on the database server host. The application resources consumed to maintain the 20 excess connections wastes valuable resources on the hosts of the applications.
Another disadvantage of other approaches is an escalating reliance by database users on hypertext transfer protocol (HTTP) requests for database services. HTTP requests for database services are popular because a user with a common client (called a “web browser,” or, simply, “browser,”) can then request database services over the Internet even without a mid-tier application. In addition, HTTP has been extended by a protocol called web-based distributed authoring and versioning (“WebDAV”) to support hierarchical operations over the internet that mimic popular file systems. However HTTP and WebDAV are stateless protocols that do not form communications channels that persist beyond a few messages. Thus, each few messages from a web browser containing requests for database services involve the creation and subsequent release of a database session object by the database server. A single user may generate dozens of messages at one sitting which involve several database connections. The repeated creation and release of database session objects consumes valuable database server resources. Such HTTP-based requests are expected to proliferate over the next few years, further taxing database server resources and degrading database server performance.
Based on the foregoing there is a clear need for techniques that service requests for database services that do not suffer the disadvantages of the above approaches and that do not degrade database server performance.
The past approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not to be considered prior art to the claims in this application merely due to the presence of these approaches in this background section.